The Java language and the JVM (Java Virtual Machine) have been designed to support concurrent programming, and all execution in takes place in the context of threads. Objects and resources can be accessed by many separate threads; each thread has its own path of execution but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "synchronized") between threads. Thread synchronization ensures that objects are modified by only one thread at a time and that threads are prevented from accessing partially updated objects during modification by another thread. The Java language has built-in constructs to support this coordination.
Contents |
The key synchronization concept for JVM concurrency is the monitor. Every object in a JVM has a monitor associated with it. Such monitor-based concurrency was originally introduced with the Mesa programming language.
The Java Language Specification does not say how the JVM designer should implement the multithreading primitives specified, because there is so much variation among the various operating systems and hardware on which the JVM is expected to run.
Since JDK 1.2, Java has included a standard set of collection classes, the Java collections framework
Doug Lea, who also participated in the Java collections framework implementation, developed a concurrency package, comprising several concurrency primitives and a large battery of collection-related classes[1]. This work was continued and updated as part of JSR 166 which was chaired by Doug Lea.
JDK 5.0 incorporated many additions and clarifications to the Java concurrency model. The concurrency APIs developed by JSR 166 were also included as part of the JDK for the first time. JSR 133 provided support for well-defined atomic operations in a multithreaded/multiprocessor environment.
Both the Java SE 6 and Java SE 7 releases introduced updated versions of the JSR 166 APIs as well as several new additional APIs.